home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / dev / www-talk.9301-9306.Z / www-talk.9301-9306 / text1498.txt < prev    next >
Encoding:
Text File  |  1995-04-24  |  4.7 KB  |  117 lines
  1. Many thanks Terry for your comments.
  2.  
  3. > Sorry not to respond sooner to your post of Monday last, pointing
  4. > out HTML+'s style attribute for PRE.  This is okay, but maybe
  5. > not the most economical approach. 
  6.  
  7. > I think there are two issues:  1) the spec's definition of 
  8. > leading white space and line breaks as significant within PRE, 
  9. > and 2) font changes within PRE.  Presently, 1 seems to work just 
  10. > fine (at least in xmosaic and lynx, the two browsers I'm using 
  11. > for trials), so it should not be necessary to institute a <BR> 
  12. > tag to get line breaks within PRE.  Outside PRE one shouldn't 
  13. > need them (counterexamples welcome).
  14.  
  15. One use is for <BR> with <P CENTER> to get some centred lines, but which
  16. all belong to the same logical paragraph.
  17.  
  18. > Presently, however, PRE is defined as having typewriter type
  19. > as its default font, and I think that's wrong.   I'd rather have
  20. > to invoke that font (by <CODE>) explicitly, the default font
  21. > remaining the same as the main text.  That way I don't need
  22. > an <R> tag, which has also been suggested, and when I
  23. > have an address to display, I can type:
  24. > <PRE>
  25. >        Name
  26. >        Address
  27. >        Telephone.  
  28. > </PRE>
  29. > and get three indented lines in the main text font.
  30. > I think that if the definition of PRE is changed in this way
  31. > the style attribute might not be needed.
  32.  
  33. I'm not sure that most people would agree with your preference to explicitly
  34. invoking a fixed pitch font.
  35.  
  36. Rather than an <R> tag, I would like to augment the EMPH rendering hints to
  37. include additional font types beyond TT. This has a certain feeling of
  38. completeness to it. The obvious step is to then also include the same font
  39. attributes in PRE (defaulting to fixed pitch), i.e.
  40.  
  41. <!ATTLIST PRE
  42.     id      ID      #IMPLIED -- link destination --
  43.     style   CDATA   #IMPLIED -- various styles --
  44.     tr      (tr)    #IMPLIED -- render in serif (Times Roman) font --
  45.     hv      (hv)    #IMPLIED -- render in sans serif (Helvetica) font --
  46.     width   NUMBER  #IMPLIED -- e.g. 40, 80, 132 -->
  47.  
  48. e.g.
  49.         <PRE TR>
  50.                 Name
  51.                 Address
  52.                 Telephone
  53.         </PRE>        
  54.  
  55. With PRE right aligned text would only work in a particular window size.
  56. PRE stops the browser from being able to adjust margins etc. to get the
  57. alignment ok for the current window size. I would therefore like to allow
  58. greater flexibility for normal paragraphs via rendering hints, e.g. your
  59. example becomes:
  60.  
  61.         <P INDENT>
  62.         Name<BR>
  63.         Address<BR>
  64.         Telephone.
  65.  
  66. The change to a container model for the P tag ensures that the scope is well
  67. defined. The style attribute for PRE should be retained so that authors can
  68. indicate the logical role of the preformatted text in an extensible manner.
  69.  
  70. On the subject of changing fonts, thanks for your comments on using the SGML
  71. external entity mechanism.
  72.  
  73. > We already have character entities in the HTML DTD; all that's 
  74. > needed is to establish how to reference external entity sets not 
  75. > actually included in the HTML+ DTD.  SGML rather envisions that
  76. > the entity files are available locally at run time; for WWW it
  77. > might be better to be able to indicate the entity files are on
  78. > the same machine the document is being fetched from.
  79.  
  80. As far as Latin-1 goes it is a simple matter to map entity definitions to an
  81. 8-bit ASCII code. More generallt, this breaks down into two parts:
  82.  
  83.     a)  mapping the entity name to a character code and char set
  84.  
  85.     b)  how to render fonts in this char set (at least for the
  86.         character codes needed for the current document)
  87.  
  88. It would be neat if we could use outline fonts for this. From the point
  89. of view of HTML+ all that is needed is (a). The rest is a matter for the
  90. protocol spec. Perhaps for now we need a mechanism like #INCLUDE that
  91. works across the network. This could be implemented using the LINK tag.
  92.  
  93. > And if we can reference external entities, we can do something
  94. > requested this week in my office:  use entities to represent
  95. > URLs.  Than means 1) URLs themselves may be extracted from the 
  96. > main document and collated in a referenced navigational document,
  97. > and 2) common link types may be generated automatically:  for
  98. > any "Next" link, my &next; entity can refer to a script that 
  99. > looks through a list of filenames, chooses the one after the 
  100. > current file, and returns that as the URL for the target of 
  101. > the link.  
  102.  
  103. Tell me more about the reasons people were asking for this feature.
  104.  
  105. It seems to me that Next and Previous can be adequately handled using
  106. the existing framework:
  107.  
  108.     a)  defined by LINK elements with REL attribute
  109.     b)  sequences defined with the GROUP tag in the parent doc
  110.  
  111. These will need to be clarified in the RFC for HTML+.
  112.  
  113. Regards,
  114.  
  115. Dave Raggett
  116.  
  117.